1. Field of the Invention
The present invention relates to methods for header compression/decompression in packet transmission and, more specifically, to a method for header compression/decompression, where reference information is requested to be updated when an error occurs in packet transmission.
2. Description of the Background Art
Typical protocols recently known for data transmission over the Internet include TCP/IP (Transmission Control Protocol/Internet Protocol) and UDP/IP (User Datagram Protocol/Internet Protocol). In data transmission under such transmission protocol over a low and midrange bit rate transmission path, the header specified by TCP, UDP, IP, or other protocols is larger in size, disadvantageously causing overhead associated with communication. For example, to transmit 10-byte data under UDP/IP, the transmitting side has to add a 28-byte header to the original data, resultantly forming a 38-byte packet, which is approximately four times larger in size than the original data. If such increase in size happens quite often, the transmission path is substantially decreased in effective speed.
In order to reduce communication overhead caused by the header, a header compression scheme developed by V. Jacobson and defined in RFC 1144 and RFC2508 has been known. In this scheme, among the fields of the header included in the packet, transmitted are only any field changed in value from the one included in the previous packet. Such field changed in value are not so many in the header, and therefore, in this scheme, header compression is successfully carried out. This header compression scheme, however, is a standard for wired communication with a low transmission error rate, as shown in FIG. 5, and is not efficient for a transmission path with a high transmission error rate.
FIG. 6 shows a communication network for wireless terminals over a cellular phone network such as W-CDMA. In recent years, the number of users of such communication network is rapidly growing. The communication network of FIG. 6 includes a wireless transmission section where errors frequently occur. To reduce overhead caused by the header in a wireless section, one header compression scheme is known as ROHC (RObust Header Compression) studied by IETF (Internet Engineering Task Force). The detail of ROHC is described in “draft-ietf-rohc-rtp-00.txt (Jun. 29, 2000)”.
In ROHC, for data compression at the transmitting side (compressing side) and data decompression at the receiving side (decompressing side), reference information is shared by both sides for reference. That is, the reference information referred to for data compression at the transmitting side is also referred to for data decompression at the receiving side. By sharing the reference information, data decompression can be correctly achieved. FIG. 7 shows one example of data transmission adopting ROHC.
In FIG. 7, at the start of data transmission, the transmitting side and the receiving side each have held correct reference information α. Consider first a case where the transmitting side transmits a header H1 and data D1 to the receiving side. Before transmission, the transmitting side carries out data compression on the header H1 by referring to the reference information α. Here, the header H1 and a compressed header H′1 for transmission to the receiving side have such a relation as represented by the following equation (1).H′1=H1*α  (1) 
In the above equation (1), an operation represented by * varies for each field of the header to be compressed. For example, the operation is so carried out as follows: the field does not vary if representing a UDP port number; the field is generally increased in value by 1 if representing an RTP sequence number; and the field is increased in value by 50 if representing an RTP timestamp.
As such, the reference information α includes all information required for compression of each field as described above. Therefore, if the receiving side holds the correct reference information α having the same contents as that held in the transmitting side, the receiving side can correctly decompress the received compressed header H′1 into the original header H1, thereby obtaining the correct header H1 and data D1. Similarly, headers and data H2 and D2, H3 and D3, and H4 and D4 are transmitted after each header is compressed by referring to the reference information α.
Next, consider a case where the reference information is changed. FIG. 8 shows an example of data transmission where the reference information is changed during the transmission. In FIG. 8, after the header H2 and the data D2 are transmitted, the reference information is changed from α to β, and the header H3 is compressed by referring to the changed reference information β.
For example, assume that the RTP timestamp of the header to be transmitted is increased by 50, but, at the time of transmission of the data D3, such increase is changed to by 100. Under this assumption, the transmitting side changes the reference information α held so far containing that “The RTP timestamp is increased by 50” into the reference information β containing that “The RTP timestamp is increased by 100”. To update the reference information, as shown in FIG. 8, the receiving side refers to update information further provided to the compressed header to be transmitted (here, a header H′3).
In some cases, the reference information may be updated even if the update information is not explicitly transmitted. One example header compression scheme taken in such cases is briefly described below. In the compressed header, the sequence number is assigned 4 bits capable of representing integers from 0 to 15, but not 16 or more. Therefore, any integer N equal to 16 or more is represented by Nmod16. Thus, the receiving side finds the sequence number by using an equation L*16+ (received sequence number), where L is incremented by 1 whenever the received sequence number is changed from the maximum value (here, 15) to the minimum value (here, 0). Here, the update information is not explicitly transmitted. Instead, when the sequence number becomes larger than the maximum value, the reference information is updated on both sides.
FIG. 9 is a block diagram showing the structure of a header decompression apparatus that achieves the header decompression as described above.
In FIG. 9, a header decompression apparatus 1007 includes a packet output unit 1001, an error detector 1002, a header decompressor 1003, a packet receiver 1004, a reference information manager 1005, and an update request unit 1006.
The packet receiver 1004 receives a header-compressed packet from a transmitting side, and outputs the packet to the header decompressor 1003. The header decompressor 1003 refers to reference information managed by the reference information manager 1005 to decompress the compressed header, and outputs the header-decompressed packet to the error detector 1002. If the compressed header is provided with update information, the header decompressor 1003 updates the reference information managed by the reference information manager 1005 with the update information provided to the compressed header. The error detector 1002 detects any error in the header-decompressed packet. If not detecting an error, the error detector 1002 outputs the correctly-decompressed packet to the packet output unit 1001. If detecting an error, the error detector 1002 discards the packet as not having been correctly decompressed. The update request unit 1006 receives a notification that an error is detected by the error detector 1002, and transmits an update request to the transmitting side. Specifically, according to the above document, “draft-ietf-rohc-rtp-00.txt (Jun. 29, 2000)”, the update request unit 1006 transmits a NACK packet. The reference information manager 1005 manages the reference information for header decompression. The packet output unit 1001 outputs the header-decompressed packet.
As such, the header decompression apparatus 1007 detects any error in the compressed header. Here, typically, the compressed header is provided with a CRC (Cyclic Redundancy Code) for determining whether the header-decompressed packet has any error or not. Therefore, any error that occurred in the compressed header or a payload due to noise during wireless transmission can be detected, and the erroneous packet can be discarded.
FIG. 10 shows one example of data transmission where an error occurs due to noise during wireless transmission. In FIG. 10, a header H2 is compressed to be a header H′2, and the header H′2 and data D2 are wirelessly transmitted. During the wireless transmission, noise or other factors affect the compressed header H′2, causing an error, which is denoted by a dotted cross in FIG. 10. As a result, as denoted by a solid cross in FIG. 10, the header cannot be correctly decompressed at the receiving side, and therefore the entire packet is discarded.
Such error as described above may occur also in the compressed header with the update information provided thereto. FIG. 11 exemplarily shows a case where an error occurs in the header with the update information provided thereto, and the reference information is erroneously updated. In FIG. 11, a header H3 is compressed to be a header H′3, and the header H′3 and data D3 is wirelessly transmitted. During the wireless transmission, noise or other factors affect the update information provided to the compressed header H′3, causing a change in the update information, which is denoted by a dotted cross in FIG. 11. Therefore, at the receiving side, the reference information is erroneously updated to reference information β′, based on the changed update information, and the header H3 decompressed by referring to the erroneous reference information is not the same as the original header H3 before compression at the transmitting side. This also applies to the following headers H4 and thereafter. As a result, as denoted by a solid cross in FIG. 11, the header cannot correctly decompressed at the receiving side, and is generally regarded as having an error. Therefore, the entire packet is discarded.
In some cases, however, the header is not regarded as having an error even if it has not been correctly decompressed, and therefore the packet is not discarded. FIG. 12 exemplarily shows a case where a packet is not regarded as having an error even if the reference information is erroneously updated. In FIG. 12, the reference information is erroneously updated at the receiving side to become receiving-side reference information α′, which is different from the reference information α at the transmitting side. As a result, headers H1 to H4 are erroneously decompressed at the receiving side. Therefore, in general, CRC errors occur and the entire packet are discarded. However, according to principles of CRC, not all errors cannot be detected, and any erroneously-decompressed header may be accidentally determined as being correct. In FIG. 12, a packet containing the header H3 and the data D3 is accidentally determined as being correct, and is not discarded.
As stated above, even if no error is detected, there may be a decompression error caused by noise or erroneous reference information. Also, even if one decompression error is detected, it is impossible to tell the cause of the decompression error, that is, either noise or erroneous reference information. Therefore, according to the above background art, an update request typified by NACK is transmitted whenever an error occurs. Such update request, however, is unnecessary when the reference information is correct and the error is caused only by noise. Thus, according to the background art, the more errors caused by noise, the more unnecessary update requests are transmitted, and therefore the lower header compression efficiency becomes.